1. Field of the Invention
The present invention relates to communications of Base-24 protocol messages between a host server and an automated teller machine (ATM) via an Internet Protocol (IP) network.
2. Description of the Related Art
Automated teller machines (ATMs) have been configured for communicating with host servers using Base-24 protocol via a serial tunneling connection, referred to as bisync tunneling (BSTUN). In particular, an ATM is configured for generating Base-24 data; the Base-24 data is encapsulated into a bisync frame, according to bisync (BSC) data link protocol, that is sent over a serial connection to a host server. Hence, each ATM has a corresponding serial connection to the host server. For transport of serial data from remote ATMs, the BSC data link protocol enables enterprises to transport bisync traffic over the same network that supports their SNA and multi-protocol traffic, eliminating the need for separate BSC wide area network facilities.
FIG. 1 is a block diagram illustrating a conventional (prior art) network configured for transporting bisync traffic between an ATM 12 and a host server 14. The system 10 includes an access router 16a, also referred to as a “tail-end” router, and a headend router 16b. The tail-end router 16a and the headend router 16b include bisync tunneling (BSTUN) resources 18 that enable the transport of bisync traffic across an IP network 20, for example the Internet or a private TCP/IP based wide area network.
In particular, the BSTUN resource 18a is configured for encapsulating the bisync traffic received from the serial connection 17a into IP frames, and outputting the IP frames to the headend router 16b via the IP network 20. The BSTUN resource 18b receives the IP frames from the network 20, removes the IP headers, and presents the bisync traffic from the ATM 12 to the bisync host 14 via a corresponding serial connection assigned for that ATM 12, for example the serial link 17b. Note that alternative encapsulation methods may be used, for example High Level Data Link Control (HDLC) protocol may be used as an alternative encapsulation method for point to point links; frame relay is another alternative encapsulation method when transporting over frame relay circuits where IP routing is not necessary (e.g., where both the tail-end router 16a and the headend router 16b are directly attached to a frame relay network instead of the IP network 20).
The BSTUN resources 18 support point-to-point, multi-drop and virtual multi-drop BSC connections. In point-to-point BSTUN passthrough operation, the bisync traffic between the two point-to-point devices (e.g., the ATM 12 and the host server 14) are received and forwarded transparently by the BSTUN resources 18. The procedures for establishing a transmission link between the end devices 12, 14 are handled by the end devices themselves, with data and control frames encapsulated with a BSTUN header and forwarded, and the peer router removing the header and forwarding the bisync data to the proper serial port 17. In particular, each BSTUN resource 18 includes a TCP/IP encapsulation resource 21 for encapsulation of the bisync frame and transfer to the peer resource 21 via a TCP/IP tunnel, a direct connect resource 23, and/or a frame relay encapsulation resource 25 for encapsulation of the bisync frame and transfer to the peer resource 25 via a frame relay connection.
In cases where bisync local acknowledgment (BSC LACK) is needed, the routers 16 include bisync resources 19. The bisync resource 19b implemented within the headend router 16b includes a pollee state machine 24 to simulate a secondary end device (e.g., an ATM) responding to polls from the host server 14. The bisync resource 19a implemented within the tail-end router 16a includes a poller state machine 26 to perform the primary polling operations (e.g., simulating the host server 14) by sending poll requests to the ATM 12. Hence, in the case of BSC local acknowledgment, only the data frames are encapsulated with a BSTUN header and forwarded by the router 16. Management of control unit (CU) states between the poller and pollee are managed by a bisync local acknowledgment application programming interface (BSC LACK API) 28, which adds a BSC LACK header before sending packets to the BSTUN resource 18. An SNMP agent (not shown) is used for tunnel state changes in the IP tunnel between the routers 16.
A fundamental problem with the arrangement of FIG. 1 is that the disclosed implementation of transporting bisync traffic across a network using B STUN is based on the design assumption that all devices (e.g., the ATM 12) that send and receive bisync protocol data frames are serially attached to the host server 14; hence, the routers 16 are used to terminate the serial lines 17 and send the bisync traffic over a common wide area network 20 along with the associated SNA and multi-protocol traffic. Hence, deployment of the system of FIG. 1 would require multiple external serial processors 22 coupled to the host server 14 for the respective deployed ATMs 12, limiting scalability and resulting in increased costs due to connecting multiple external serial processors 22 to the host server 14.
Newer automated teller machines are TCP/IP based and connect to a host server via an IP network 20, enabling the host server to communicate with the automated teller machines via a local area network and wide area network. However, such TCP/IP based ATMs lack management support, as found in legacy ATMs utilizing bisync protocol as illustrated above with respect to FIG. 1. In particular, the host server may be unable to determine connection status of a TCP/IP based ATM to determine, for example, whether the ATM utilizing TCP/IP connections needs user intervention.